/api/user-data trusts an x-wallet-address header - #10

Summary

This PR secures the /api/user-data endpoint and replaces the race-prone file-based user data store with durable server-side storage.

Previously, the API trusted the client-supplied x-wallet-address header as the user's identity. This allowed any client to access, modify, or delete another user's data by providing their wallet address. User data was also stored in a single JSON file, where concurrent read-modify-write operations could overwrite each other's changes.

This change derives the wallet address from a verified authentication token and moves user data to a durable storage backend while preserving the existing UserDataSnapshot shape.

Changes

• Added authentication checks to GET, PUT, and DELETE /api/user-data.
• Derive the user's wallet address from the verified JWT walletAddress claim instead of trusting x-wallet-address.
• Ignore forged or mismatched x-wallet-address headers when an authenticated identity is present.
• Reject unauthenticated requests.
• Replaced the single-file JSON persistence layer with durable server-side storage.
• Prevented concurrent updates from silently overwriting another user's changes.
• Preserved the existing UserDataSnapshot structure to avoid unnecessary changes to consumers.
• Updated the user data flow where necessary to work with the authenticated identity.
• Added security and persistence tests covering cross-user access and forged headers.

Security

The previous implementation allowed requests such as:

GET /api/user-data
x-wallet-address: another-users-wallet

to access another user's data.

The API now requires a valid token and derives the wallet address from the authenticated identity. The client can no longer select which user's data to access simply by changing a request header.

Testing

• Verified unauthenticated GET, PUT, and DELETE requests are rejected.

• Verified an authenticated user can access their own data.

• Verified a client cannot access another wallet's data by modifying x-wallet-address.

• Verified a forged x-wallet-address is ignored when a valid authenticated identity is present.

• Verified user data persists across application restarts.

• Verified concurrent saves do not silently discard updates.

• Ran:

  • npm run type-check
  • npm run lint

Files Changed

• app/api/user-data/route.ts
• lib/server/userDataStore.ts
• lib/api/userData.ts
• hooks/useUserDataSync.ts
• Relevant tests and configuration for the new persistence/authentication flow

Acceptance Criteria

• User data endpoints require a verified authentication token.
• Wallet identity is derived from the authenticated token.
• x-wallet-address cannot be used to impersonate another user.
• User data is stored durably rather than in a single local JSON file.
• Concurrent updates do not silently overwrite user data.
• Existing UserDataSnapshot consumers continue to work.
• Security and persistence behavior is covered by tests.

Closes #4